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Commissioner of Patents 



Sir: 

This is an Appeal Brief under 37 C.F.R. § 1 .192 in connection with the decisions of 
the Examiner in an Advisory Action mailed on March 20, 2002. Each of the topics required 
by Rule 192 is presented herewith and is labeled appropriately. 

(1) Real Party In Interest 

The real party in interest is Citicorp Development Center, Inc. (formerly Transaction 
Technology, Inc.) 

(2) Related Appeals And Interferences 

There are no other appeals or interferences related to this case. 

(3) Status Of Claims 

Claims 14-27 are pei)ding and rejected. Claims 14-27 are hereby appealed. 
10/23/2002 ftUOHDAFl 00000082 09240588 
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(4) Status of Amendments 

There are no outstanding amendments. 

(5) Summary Of The Invention 

The present invention is directed to a system and method for automatically 
harmonizing access to a given software application program via different access devices. 
Through use of the method and system, a financial institution can provide access to a desired 
application (such as, for example, automatic bill payment services) to customers using 
different access devices such as web browsers, screen phones and personal computers. A 
single application program is all that needs to be written and maintained by the financial 
institution. Page 3. lines 11-17 . 

The invention achieves the aforementioned objectives by receiving information from 
the user via the user's access device, including information identifying the type of device 
being used and the application program the user wishes to access. The application program 
is then accessed and the information to be displayed to the user is identified. This 
information is automatically translated into a format which is compatible with the device, 
including its display, and sent to the device for display. Page 3, lines 22-28 . 

In order to be processed by a token-creator-mapper into a desired format for the user's 
device, the application stream of the desired application needs to contain tokens. A token or 
tag is a single element of an encoding language. As used by the present invention, a token is 
an element of the electronic communication language used between the financial institution's 
application software and the token-creator-mapper. Therefore, by adding a token 
representation to an application stream en route to a customer, one is ensured that the 
application stream will be in a form comprehensible by the customer's computer system. 
Paee5. lines 10-19 . 

When an application stream contains data without any tokens, the stream may be 
directed to a parser, which then adds a token representation or tokenizes the application 



U.S. Serial No.: 09/240,588 



-3- 



DocketNo. CITI0035-CON 



stream. The tokenized application stream is then directed to the token-creator-mapper, which 
maps the application stream into a token representation that is understood by the user's 
device. Page 5, line 20 - Page 6, line 12 . 

(6) Issue 

Whether the Examiner's rejection of claims 14-27 under 35 U.S.C. 102(e) as being 
anticipated by Nguyen et al. (U.S. P. No. 6,072,870) is proper. 

(7) Grouping of Claims 



Claims 14-27 are arranged into 3 groups, wherein the claim(s) in each group stand or 
fall together for purposes of this appeal. 



GROUP 


CLAIMS 


(1) 


14-18, 22, 23, 26, and 27 


(2) 


19-21 


(3) 


24, 25 



(8) Argument 

The Rejection of Claims 14-27 Under 35. U.S.C. § 102(e) As Being Anticipated by 

Nguyen et al. is Not Proper 

Despite a Response to Final Office Action differentiating Nguyen et al. from the 

claimed invention, as filed on February 19, 2002, the Examiner maintained the rejection of 

pending claims 14-27 in the Advisory Action, stating in general that, 

"Applicant argues that Nguyen et al. does not teach 'a random capture token to 
associate the payment capture request. . .". As specified by the Examiner in the 
[Final] Office Action mailed on 1 1/19/2001, page 4, lines 1-5, this limitation is 
disclosed by Nguyen." 

Once again, this rejection is respectfully traversed for at least the following reasons: 
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With regard to claims 14-18, 22, 23, 26, and 27, the Examiner asserted that the 

claimed limitation of "creating a token representative of the data stream from the desired 

application" is disclosed by Nguyen et al. in col 18, lines 48-67, specifically, 

"wherein it is stated payment gateway computer system generates a random capture 
token. Random capture token is utilized in subsequent payment capture processing 
to associate the payment capture request with the payment authorization request 
being processed, please note that the process of utilizing or generating token by the 
computer system in subsequent payment capture is readable as the process of creating 
a token representation of the data." (Emphasis added). See Final Office Action of 
11/19/01, p. 4. 

As admitted by the PTO in the aforementioned paragraph, Nguyen et al. actually teach away 
from the claimed invention because their payment gate computer system merely generates a 
random capture token to associate the payment capture request with the payment 
authorization request Thus, the process of utilizing or generating a token by the computer 
system of Nguyen et al. in subsequent payment capture is not readable nor can it be 
interpreted as the process of "creating a token representation of a data stream of the desired 
application" as claimed. In other words, the capture token generated by the system of 
Nguyen et al. is merely a random token associating a payment capture request to a payment 
authorization request, and it is not used as a token representation of the data stream parsed 
from the desired application (i.e., the payment capture request or the payment authorization 
request, if they can even be considered as applications) as claimed. 

Claims 14-18, 22, 23, 26, and 27 stand or fall together with regard to the rejection 
under 35 USC § 102(e) as being anticipated by Nguyen et al. for purposes of this appeal. For 
the reasons stated above, it is respectfully requested that the Board recognize the deficiencies 
in the Examiner's rejection of the claims, reverse the Examiner's rejection, and allow claims 
14-18. 

With regard to claims 19-21, they are allowable over Nguyen et al. and other 
references of record for the same reasons set forth above with regard to claims 14-18. 
Furthermore, Nguyen et al. fail to disclose the features of claims 19-21, namely, "a token- 
creator-mapper for creating a first token representation and a second token representation 
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of the data provided by the application that are respectively received by the first access 
device and the second access device." (Emphasis added). 

Claims 19-21 stand or fall together with regard to the rejection under 35 USC § 102(e) 
as being anticipated by Nguyen et al. for purposes of this appeal. For the reasons stated 
above, it is respectfully requested that the Board recognize the deficiencies in the Examiner's 
rejection of the claims, reverse the Examiner's rejection, and allow claims 19-21. 

With regard to claims 24-25, they are allowable over Nguyen et al. and other 
references of record for the same reasons set forth above with regard to claims 14-21. 
Furthermore, the process of authorizing credit in the system of Nguyen et al. is not readable 
nor can it be interpreted as the process of identifying the data stream as a legacy application 
stream, as asserted by the Examiner. See Final Office Action of 1 1/19/01, p. 3. This is 
because the random token representation in col. 18, lines 48-65, cited by the Examiner is not 
a created token representation of the authorizing credit data stream of Nguyen et al., i.e., the 
legacy application stream as stated in claim 24. 

Claims 24-25 stand or fall together with regard to the rejection under 35 USC § 102(e) 
as being anticipated by Nguyen et al. for purposes of this appeal. For the reasons stated 
above, it is respectfully requested that the Board recognize the deficiencies in the Examiner's 
rejection of the claims, reverse the Examiner's rejection, and allow claims 24-25. 



For at least the reasons given above, the rejection of claims 14-27 is improper. It is 
respectfully requested that such rejections by the Examiner be reversed and claims 14-27 be 
allowed. Attached below for the Board's convenience is an Appendix of claims 14-27 as 
currently pending. 



Conclusion 
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(9) Appendix 

14. A method of interfacing a plurality of different access devices to either a legacy 
application or a canoncial application comprising; 

parsing a data stream from the desired application if the desired application is a 
legacy application; 

creating a token representation of the data stream from the desired application, 
regardless if the application is a legacy application or a canonical application; and 
forwarding the token representation to one of the plurality of access devices. 



15. The method of claim 14 further comprising: 
displaying the data stream on the one access device. 



16. The method of claim 14 wherein the one access device is a home computer. 

17. The method of claim 14 wherein the one access device is a personal digital 
assistant. 

18. The method of claim 14 wherein the one access device is a screenphone. 



19. A system for distributing information to a plurality of customers comprising: 

an application for providing data in response to a request for data; 

a token creator-mapper for creating a first token representation of the data provided 

by the application and a second token representation of the data provided by the application; 

and 

a plurality of different access devices for each of the plurality of customers wherein a 
first access device receives the first token representation of the data and the second access 
device receives the second token representation. 
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20. The system of claim 19 wherein the first token representation and the second 
token representation of data include data specific to one customer. 

21. The system of claim 19 wherein the first token representation and the second 
token representation of data include data generic to the plurality of customers. 

22. A method of interfacing an access device with a software application, 
comprising: 

producing a data stream from the software application; 

providing a token representation of the data stream from the software application; and 
forwarding the token representation to the access device. 

23. The method of claim 22, wherein providing the token representation of the data 
stream from the software application comprises: 

identifying the software application as one of a legacy application and a canonical 
application. 

24. The method of claim 23, wherein providing the token representation of the data 
stream from the software application further comprises: 

if the software application is identified as a legacy application, identifying the data 
stream as a legacy application stream; 

determining that no token representation exists for the legacy application stream; and 
creating the token representation of the legacy application stream. 

25. The method of claim 24, wherein forwarding the token representation to the 
access device comprises: 

mapping the token representation to a token stream that is particular to a renderer of 
the access device. 
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26. The method of claim 23 , wherein providing the token representation of the data 
stream from the software application further comprises: 

if the software application is identified as a canonical application, identifying the data 
stream as a canonical application stream having the token representation of the canonical 
application stream. 

27. The method of claim 22, wherein forwarding the token representation to the 
access device comprises: 

mapping the token representation to a token stream that is particular to a renderer of 
the access device. 



